Advenced system and method for dynamically discovering, providioning and accessing host services on wireless data communication devices

ABSTRACT

A system and method for pushing a service book to a mobile device is provided. A service book includes a plurality of fields relating to a host service. At least one mobile device is identified that is to receive the service book. Wireless propagation information is provided that identifies an address for the mobile device to receive the service book. The service book is transmitted over a wireless network using the address for the mobile device, and is received by the mobile device.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority from and is related to thefollowing prior application: Advanced System and Method for DynamicallyEnabling Host Services on Wireless Data Communication Devices, UnitedStates Provisional Application No. 60/283,315, filed Apr. 12, 2001. Thisprior application, including the entire written description and drawingfigures, is hereby incorporated into the present application byreference.

FIELD OF THE INVENTION

[0002] The present invention is directed toward an advanced method ofdiscovering, provisioning and accessing host services on one or morewireless data communication devices. When a user of a wireless mobiledevice (“mobile device”) wants to expand the usefulness of theirinvestment, they add services and features to the device. The problem ofdiscovering an available wireless service is just one of severalproblems faced by the user of a mobile device. Once discovered, the useralso has to be provisioned to use the service and finally theprovisioned application must contact the host that is providing theservice itself. The present invention provides a loosely coupled systemso that mobile devices can be dynamically added or removed from a hostservice with relative ease.

BACKGROUND OF THE INVENTION

[0003] In the area of land-line solutions and the use of the Internet,the most common solution for solving the discovery and integration ofnew services is through Universal Description, Discovery and Integration(UDDI). UDDI provides a browser and Application Program Interface (API)centric view of dealing with dynamic services. The browser method treatspotential service users as always online. The API method also assumesalways online and continuous high speeds for program to programcommunication. The UDDI method of host service registration is describedby the following documents found on the www.uddi.org Internet web site:Version 2.0 Programmer's API Specification, Version 2.0 Data StructureSpecification, Version 2.0 Replication Specification Version 2.0Operator's Specification, Executive White Paper (version 1.0), TechnicalWhite Paper (version 1.0), Using WSDL in a UDDI Registry 1.05, UsingWSCL in a UDDI Registry (1.02) and Providing a Taxonomy for Use in UDDIVersion 2.

[0004]FIG. 1 describes a simplified view of the relationships depictedand expected in the UDDI specifications. In UDDI the business user 2 isthe center of attention as they justify the presence of the service bypaying for the service. Business users 2 are motivated to use and findservices to solve real-world business problems. Business users 2 usemarketplace web sites 4 and search portals 6 to find required webservices. The UDDI service cloud 8 acts as a worldwide repository ofservice information 10 that is accessible in a distributed mannerthrough a network like the Internet. Behind the service cloud areactually databases 10, perhaps using LDAP services or some other fastlook-up technology to satisfy service requests. These databases 10 mightbe distributed around the globe and may communicate using a UDDIpropagation technique as defined in the UDDI specification. Populatingthese databases 10 are technical users 14 that write software thatincludes UDDI protocols and practices 12. These programs register theirservice information in the large service registry system. This trianglerelationship just described is the bases of the majority of the UDDIspecification.

[0005] UDDI and other similar types of service registry definitions alldefine a central store where all services can be found if desired. TheUDDI specifications describe ways to manipulate, change and replicatethis information between databases in the UDDI cloud. Additionally theservices are categorized into Taxonomies to further help with locatingand identifying the service needed.

[0006]FIG. 2 is an illustration of the relationships between a serviceoffering 16, a service listing 20 and a service user 18 in a UDDIenvironment This three-way relationship has its advantages for landlineenvironments, but needs modification and extending for wirelessenvironments. Essentially, a company, person or organization decidesthey want to create a public or semi-public service that should be madeavailable to a wide audience of users. The service creator 16, or theeventually service provider 16, propagates the service information to acentral registry of public services 20. In addition, a third party maydevelop the software, and each time it is purchased and installed a newservice registry entry is created. Alternatively, a single company maycreated the service and also offer it to the public. Another possibilityis that several companies may build a service and each run a similarversion of the service.

[0007] Within the service registry 20 further propagation takes place sothat the service information is distributed throughout the entire systemof service registries 10. Essentially the act of publishing the serviceinformation once, allows for a “publish once access anywhere” designapproach. This publishing can be done programmatically or through manualprocesses through the UDDI API definitions. Part of UDDI is a rich setof XML and SOAP-based commands that allow service providers to securelyestablish, modify and delete entries in the registry database 20.

[0008] The service listing 20 provides a source of new services forservice users 18. Service users are typically web browser users, butcould also be programs looking for services. This helps to support webcrawlers that are building service listings and search portalinformation. Users typically start up web browsers to search for serviceinformation and perform searches until the information is found. Thismodel is based on a request/response model, or a pull architecture. Thisdesign is important because it is the only way for the user to accessweb-based service registries in landline environments. The serviceinformation exchanged follows a ridge format that is also shown in FIG.2.

[0009] The overall service information 22 has been labeled service book30 for ease of reference. The use of UDDI to define the form of aservice book 30 is present only for illustration. UDDI is well known andis currently defined as a note in the W3C. However, there are many otherformats, definitions and proprietary methods to define a service book 30that would have a similar functionality. The service book in the UDDIXML schema represents four main XML core types of information. Thesefour information types include business information 22, serviceinformation 24, binding information 26 and service specific information28. These information sections are build in hierarchies and aresub-sections of the layer above it. These types of information groupsprovide different levels of functionality. The business informationsection 22 allows top-level searching for company names and companysectors; these are often called ‘white pages’. Different taxonomies areprovided to find companies that service a specific industry or who arelocated in a given region of the country; these are often called ‘yellowpages’. Further within the business information section 22 aresub-sections for defining service information 24, binding information 26and detailed service information 28; these are often called ‘greenpages’. Service information 24 includes a grouping to define commonservices for further categorization. Binding information 26 includesrouting information to find the service, either through URI (URL) typereferences or some other proprietary numbering method. The detailedservice information 28 includes capabilities of the service and defineelements like security level, data formats, database types, specificdata access schemas and many other possible data exchange requirements.There are many other components of the UDDI XML schema but for thisdescription these sections indicate a possible definition for a servicebook 30 entity.

SUMMARY

[0010] A system and method for pushing a service book to a mobile deviceis provided. A service book includes a plurality of fields relating to ahost service. At least one mobile device is identified that is toreceive the service book. Wireless propagation information is providedthat identifies an address for the mobile device to receive the servicebook. The service book is transmitted over a wireless network using theaddress for the mobile device, and is received by the mobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011]FIG. 1 describes a simplified view of the relationships depictedand expected in the UDDI specifications;

[0012]FIG. 2 is an illustration of the relationships between the serviceoffering, the service listing and the service user,

[0013]FIG. 3 illustrates two methods for discovering host services andthen accessing those services;

[0014]FIG. 4 illustrates two additional methods for discovering hostservices beyond those shown in the prior art;

[0015]FIG. 5 shows three sample service offerings and how service bookscan be exchanged between the service offerings and the mobile device;

[0016]FIG. 6a is a presentation of an innovative user interface (UI) forservice book entries on a handheld device;

[0017]FIG. 6b shows an example of what the service book sub-system mightlook like on the mobile device;

[0018]FIG. 7 is an exemplary example of provisioning in a wirelessenvironment;

[0019]FIG. 8 uses a sequence diagram to illustrate the steps necessaryin an exemplary method of provisioning;

[0020]FIG. 9 is one sample internal design for the service bookcomponents on the service offering and the mobile device;

[0021]FIG. 10 represents a flow diagram for how a UDDI Registry node myhandle a modified UDDI XML schema message;

[0022]FIG. 11 represents a flow diagram for how a host service preparesand send a service book;

[0023]FIG. 12 represents a flow diagram for how a service book isprocessed on a handheld device;

[0024]FIG. 13 represents a flow diagram for how the user interacts withthe service book sub-system on a handheld device; and

[0025]FIG. 14 is a block diagram of a mobile communication device 100 inwhich the dynamic expansion of host services may be implemented.

DETAILED DESCRIPTION

[0026] 1. System Overview of Service Discovery And Access

[0027]FIGS. 3 and 4 illustrate exemplary methods for discovering serviceofferings 16 (for example web services) and then accessing thoseservices using a wireless data communication device 100. FIG. 3 alsoillustrates that a UDDI method for accessing the service registry isalso supported from a mobile device 10 b, but is problematic. Theexemplary methods illustrated in FIGS. 3 and 4 each utilize a servicebook 30, 32, which may, for example, include the following fields:

[0028] (1) Business Elements: Company Name, Address and other CompanyInformation;

[0029] (2) Service Elements: Name of Service, Purpose of Service, Costand Billing Issues, Service Identifier String (Application Link);

[0030] (3) Routing Information: Service Book identifier, Routinginformation of service, Id of service and other identificationinformation;

[0031] (4) Detailed Service Information: Service features (compression,encryption, packaging), type of packaging, types of mobile devicessupported (i.e. form factor, screen sizes, etc), content type of dataexchanged (MIME, HTML, XML, Java, Proprietary, etc);

[0032] (5) Wireless Information: destination device identifier 1, devicetype, delivery method for sending service book, destination deviceidentifier ‘N’;

[0033] (6) Provisioning Information: provisioning required flag, type ofprovisioning, URL or address of provisioning site, MIME type ofdownloadable item.

[0034] Wireless Information is applicable when the Service Registry isbeing asked to forward the information to additional locations. Many ofthese items will be described in greater detail in the figures tofollow. The service identifier string for example is used on the mobiledevice 100 to assist applications to locate the correct service bookinformation for provisioning purposes. (Part of extended service book32).

[0035] Provisioning Information is applicable for advanced service bookoperations, especially when application downloading is required. Therouting information of service (URL) may be used after the applicationis downloaded to the user's mobile device. (Part of extended servicebook 32).

[0036] Turning now to FIG. 3 there are two paths labeled (A) and (B).The path labeled (A) illustrates that it is possible to utilize a UDDImethod to emulate the behavior of a traditional landline web browserwith a wireless browser. The information retrieved can be presentedusing a format like WML (wireless markup language) so that the user canview the business information before deciding what to do. This UDDImethod, however, typically requires wireless speeds that make findingthe correct service slow and time consuming on a mobile device 100 b. Inaddition, when a user is in poor or marginal coverage areas, the mobiledevice 100 b is typically unable to search for services. Without havinga cache of services on the mobile device 100 b this would mean thataccess to services may also be impossible when coverage is notavailable.

[0037]FIG. 3 also illustrates a new method for populating the servicebook, labeled (B), where the UDDI service cloud 8 receives a servicebook entry 32 and pushes the extended service book entry 32 to themobile device 100 a. Note: the extended service book 32 might have thewireless section removed, since it is only used by the UDDI serviceregistry to push service books 32 to mobile device. Note: the servicebook might also have no provisioning section, so it could become anoriginally defined UDDI service book 30. This could be mistaken forsimply extending the UDDI service cloud 8 to include mobile devices 100,but this is not the case. In fact if that were tried the memory andprocessing power on the mobile device 100 would typically make thesystem unusable. To get around this problem of simply extending the UDDIservice cloud 8 the invention uses a method of sending only targeted andaddressed service books 32 to one or more mobile devices 100. Using thistargeted method the service book listing on the mobile device 100 is amanageable size and the user has greater control of what services arekept and which are ignored. Otherwise if hundreds or thousands ofservice books were being sent to the mobile device 100 the user wouldnever be able to keep up with the vast number of updates, and thedevice's memory and battery would be insufficient for the job.

[0038] To emphasize this targeted approach, example (B) in FIG. 3 showsthe UDDI service registry 8 being given a service book 32 withadditional information (++). The plus, plus (++) will be described laterbut includes advanced wireless propagation information not currentlydefined in the UDDI specification. In this situation the serviceprovider 16 is aware that the type of service being offered is wirelessready. This can mean several things, it could mean that the service isdesigned specifically with mobile devices in mind, or it might also meanthat the service can be presented so that wireless browsers and landlinebrowsers can both access the service. It is not necessary that a webservice support only web browsers, but also Java-based program could beused to interface with the host service. When using this feature theservice provider 16 would also have to add mobile device routinginformation for this advanced propagation. The addition of thisinformation to the UDDI XML schema would indicate to the UDDI registrythat the information is to be pushed to the listed wireless addresses.

[0039] Within a service book 32, would be an additional section known asthe “Wireless Information” section that described the addresses ofmobile devices that should receive the pushed service book 32. Thisaddress list could either be IPv4 addresses, IPv6 address, proprietarynetwork addresses, or some Personal Information Number (PIN) of themobile device, as described below in greater detail. The full extensionwould have many elements within the Wireless Information part of the XMLschema for a UDDI service book exchange, or some other elements in otherproprietary or non-proprietary formats that might be used. Some of theelements would be (a) binding key value which identifies the instance ofthe wireless information structure, (b) one or more service key valueswhich identifies one or more mobile devices, (c) access point value anoptional value that could be present as a gateway address for reachingthe mobile, and (d) access method which defines whether TCP/IP, UDP/IPor some other proprietary method like IPv6 over TCP/IPv4 or e-mailshould be used to send the service book. The address of the mobiledevice 100 a could be a proprietary network address, an IPv4 address, anIPv6 address, an e-mail address or some specialized personal informationnumber (PIN). It is also expected that if a UDDI method were to be usedto propagate the service book to a mobile device 100 a, only one or morespecialized UDDI nodes 10 in the node cluster 8 would be capable ofrecognizing and delivering the information to the wireless network.

[0040] Method (B) also takes advantage of the fact that the mobiledevice 100 a can support pushed information. One such method for pushinginformation to a mobile device is described in “System And Method ForPushing Information From A Host System To A Mobile Device Having AShared Electronic Address,” U.S. Pat. No. 6,219,694, which is owned bythe assignee of the present application, and which is herebyincorporated into the present application by reference. By pushing theinformation to the mobile device 100 a, the wireless user get immediatenotification of the new service and can accept or reject the new servicethrough a specialized user interface. This user interface is detailed inFIG. 6. Once the service book 32 is on the mobile device it can becached and used at any time. This caching method will also act as astepping-stone to full service provisioning, discussed later in thisapplication. Once the service book 32 is on the mobile device 100 a theapplication can directly access the service, probably using an Internetlink, not shown in this figure.

[0041] Turning now to FIG. 4 there are two more advanced wirelessmethods shown. The first is labeled method (C). This new method is awireless specific method that enables the wireless user immediatereception of the service book 32 directly on the mobile device 100 c.This service book could follow the UDDI XML schema, a proprietary schemaor some other new service book standard not yet released. This wirelessspecific method (C) of propagating the service book 32 assumes a directrelationship between the service offering 16 and the user of the mobiledevice 100 c, or the service user. In the wireless world these closerelationships are traditional and very common. This occurs because mostwireless service offerings are customized and tailored for one or moremobile devices of choice. This relationship will be further emphasizedlater in the provisioning section with the use of specialized protocolsand programs like Sun Microsystem's Java 2 Micro Edition (J2ME). One ofthe most common methods for delivering the service book 32 to the mobiledevice 100 c would be using e-mail. This would use SMTP to deliver themessage and the service book 32 would be contained within a MIME part ofthe message. It is also likely using e-mail that the service book 32MIME part would be encrypted for security using a key that only thedestination mobile device 100 c would know.

[0042] In example (C) the service offering 16 maintains a list ofcustomers or mobile device 100 c to customer relationships, and is ableto send out one or more service books 32 to the mobile device 100 c.This allows the service offering 16 to update, delete, or extend theservice book 32 entries on the mobile device 100 c. Each time a changeoccurs to the service book cache on the mobile device 100 c, the usercould be prompted to make the final choice to accept or reject thechange. For example for trusted service offerings 16 the service bookcache might automatically get updated without user intervention. In allsituations the service book 32 should be signed and encrypted for themaximum security. Some methods described in the UDDI service exchangeprocedure, talk about signing and encrypting the service book. It iscertainly recommended that a public key or private key method be used toexchange the information. The most common case of this automatic servicebook update would be if the user acquired their mobile device 100 c fromthe same company offering the service. Once the new service has beenreceived the user of the mobile device 100 c can then access the serviceoffering 16 directly using whatever methods are allowed across thewireless network. These methods are described in more detail laterthrough the provisioning section.

[0043] Another example shown in FIG. 4 is labeled path (D). Method (D)using a close proximity method to exchange the service book 32. Thismethod provides for automatic security as the building or area beingused for the exchange should be secured to start with. However if thisis not the case, then a public, private or symmetric key should be usedto encrypt the service book 32 before it is transmitted. The mediumshown for the exchange 34 could be a wide-range of close proximitylinks. Some of the options include serial connection, USB connection, IRconnection like IRDA, a RF connection like Bluetooth, or a broadband RFmethod like 802.11 or Bran. A close proximity exchange is unique becausethere is an implicit trust relationship built, especially when a serialport or USB method is used. In cases like 802.11 the distance can begreater so greater care must be taken when supporting these types ofservice book 32 exchanges. A close proximity connection also allows forbulk data transmission, which helps with provisioning as describedlater.

[0044]FIG. 5 shows three sample service offerings and how service bookscan be exchanged between the service offerings and the mobile device.FIG. 5 puts all the major elements together to show a more complexsituation where services offerings and mobile devices co-exist. In FIG.5 there are many host services shown and a sample network topology thatinterconnects WAN networks like the Internet 130 and wireless networks150. One skilled in the art can appreciate there could be hundreds ofdifferent topologies, and the one selected is for illustrative purposesonly.

[0045]FIG. 5 shows three sample service offerings 16, the “My ASP” or“My Company” host service 16 a, the “My ISP” host service 16 b and“Joe's E-Trade” host service 16 c. Within the ASP 16 a (ApplicationService Provider) or My Company 16 a (my corporation) environment are aseries of personal services used by the wireless users. When it is theuser's company providing the service normally a firewall 64 is presentto protect all company secrets. This does not mean that firewalls arenot used with ASP, ISP and private services, only that corporationsnormally always have a firewall 64 present. When an ASP 16 a isproviding a service it might focus on: integrated e-mail, calendar, taskand information services, exactly the same as my corporate environment16 a might offer. An ASP 16 a may, for example, offer these servicesbecause the company is too small to justify the IT and machine expenses.They could also provide contact information, customized database accessand a range of applications so the user can avoid installing these intheir own office. Quite recently a larger ASP 16 a like America Online(AOL) has been offering a wider range of wireless services to acommunity of mobile users.

[0046] The next example the service offering 16 is My ISP (InternetService Provider) 16 b service. Many ISPs 16 b are starting to increasetheir value and differentiate themselves by offering wireless e-mail andwireless-friendly web portal information. A good example of this isYahoo.com™ or Earthlink™ as more widely used ISPs 16 b that aresensitive to wireless users. For most ISPs e-mail is the main item theywish to provide wirelessly, but in some cases they include configurationservices and calendar services. The third example is a specific verticalsolution called Joe's E-Trade Service 16 c. This example represents aclass of services like electronic trading, financial services, bankingservices and Internet-based m-commerce (mobile commerce). Joe's E-Tradeservice 16 c also represents a large class of host services that offernothing else but a vertical application solution. Unlike the ISP that isalso offering Internet 130 access, the vertical solution is only sellingone or more specific services like stock trades and stock information,flight booking and flight information, car trading and car purchaseinformation, hotel reservations, weather information, real estateservices, map information, sport scores and sports information, careerand job information, people search and yellow pages information,business review information, games and music swap services or otherpossible host services.

[0047] In this example the topology of network connections show theInternet 130 as the main conduit to host services 16, a wirelessinfrastructure 140 and one or more wireless networks 150. The wirelessinfrastructure is an optional addition to the problem of delivering datato a handheld device 100 as it abstracts the wireless network 150 andallows a single host to reach a wide range of similar or dissimilarnetworks. A UDDI Registry system 10 or proprietary service book clearinghouse may also be provided, which has a direct connection 72 to network‘N’ 150 b. The easiest and most cost effective way for a serviceoffering 16 to send data to the mobile device 100 is typically to directit through the Internet 130. This is because most advanced host servicesalready have links to the Internet 130 using one of many ways toexchange data with existing Internet users. The number of wirelessnetworks 150 that could be linked with a wireless infrastructure 140could be very large and diverse. These networks may include, forexample, three different types of networks: (1) the data-centricwireless network, (2) the voice-centric wireless network and (3)dual-mode networks that can support both voice and data communicationsover the same physical base stations.

[0048] In each of the example host services there might be a wirelessconnector (WC) 60 present to custom the application for mobile devices100. In some cases the WC 60 could be nothing more than serving up webinformation using a Wireless Markup Language (WML) format, in othercases it might involve advanced packaging and Java access services, likefor e-mail redirection services. In many instances the wirelessconnector 60 is taking confidential and non-confidential corporateinformation and redirecting it out the corporate firewall to mobiledevices 100. To perform this action the WC 60 might be compressing,encrypting and packaging the information for delivery. In the case ofthe UDDI Registry 10, the Wireless Connector ‘(WC’) is watching for anextended UDDI XML schema 32 and detecting the Wireless Informationsection.

[0049] One advanced element of the host services 16, is that they can bebuilt to enable ‘push’ services to the mobile device 100. What thismeans is that service information can be asynchronously pushed to theuser of the handheld device 100 without a previous action beingperformed by the user. The effect could be once I have registered for aservice to get stock quotes, flight information, airfare seat sales,sport information, company inventory records, new contacts, new calendarevents, new e-mail messages and a range of other service informationpushed to my device all day and without prior action on the part of theuser. These advanced actions would be performed by the WC 60 usingprotocols like TCP/IP or UDP/IP as describe in later sections of FIG. 5.

[0050] There is also a class of financial services that are‘pull-centric’ that usually require users to log-on wirelessly toincrease security. These pull-centric and push-centric communicationmethods allow data to follow users or allows user to reach their datawherever they travel. This immediate host service availability isenhanced by the incorporated “System And Method For Pushing InformationFrom A Host System To A Mobile Device Having A Shared ElectronicAddress,” U.S. Pat. No. 6,219,694. By using some of the methodsdescribed in the earlier application the ability to dynamically push newservices to handheld devices is strongly enhanced. The experience to theuser of pushed services and data is to providing richer and richer formsof data on the device for the end user.

[0051] Turning back to My ASP/My Company (My Company) service offering16 a, its WC 60 illustrates two ways to send the service book 32 to themobile device 100. (In this illustration the service book is shown as amail message with a-book labeled ‘SB’ inside.) The My Company 16 aservice can use a close proximity link 62 (serial, RF, IRDA, Bluetooth,802.11, etc) to delivery the service book 32 to the mobile device 100 d.This method is done behind the firewall and is a unique method forpoint-to-point delivery of this critical service access information.Once this is complete the provisioning step could then take place asdescribed in the next section. Once the first service book 32 isexchanged over the serial port, other service book entries 32 can beexchanged based upon the security established by the first service book32. In an alternative embodiment the device uses a full public keyinfrastructure (PKI) and when initially started will register its publicsecurity key with the PKI. Once this is done each host service wishingto send a service book over-the-air to the mobile device simply has torequest the mobile device's key from the PKI.

[0052] The second method used by My Company 16 a is to delivery theservice book 32 through the Internet to the mobile device 100 c. Todelivery the service book 32 over this link the service offering 16 amight use an SMTP, WML or HTML method over TCP/IP, UDP/IP or some otherproprietary technique that is specifically designed for this purpose.

[0053] Turning now to the My ISP service 16 b and Joe's E-Trade service16 c they both use the central registry method for delivering theirservice book information. One embodiment would be to deliver themodified service book 32 over their respective Internet link 66 using aUDDI XML data exchange method 70 to the UDDI registry 10 or, if a UDDIregister 10 is not available, then a proprietary service book clearinghouse 10. These services 16 b and 16 c might use this method over thedirect delivery method to reduce direct dependency on the mobile device100. They might also offer both wireline and wireless services using thesame host or some programs. In this illustration the service book 32 isnot carried in a message envelope, but could be sent using a variety ofmethods over TCP/IP. These include e-mail, HTTP, Fl?, XML or HTTP, orsome other proprietary method.

[0054] Whatever delivery method is used for the service book 32, thedata items exchanged between the service offering 16 and the mobiledevice 100 via the wireless network 150 may include sensitiveinformation or confidential information. A user of a mobile device 100may also prefer that data items and service books 32 not be accessibleoutside the secure environment of the host system. In these situationsthe IT departments using a mobile device 100 might have control on howthe service book cache on the mobile device 100 gets populated. This isespecially true for the service book exchange, since it essentially‘enables’ a new service 16 to exchange information with the mobiledevice 100. An encryption scheme is therefore preferably implementedbetween each service offering 16 or the service book clearing house 10and any mobile device 100 with which the service offering 16 willcommunicate. In a private key encryption scheme, a common shared key ismaintained for each service offering 16 that wants to exchange data withthe mobile device 100. Public key encryption involves encrypting amessage with a publicly available encryption key associated with eitherthe service offering 16 or the mobile device 100. A resultant encryptedmessage may only be decrypted using a private key held by serviceoffering 16 or the mobile device depending on which direction themessage is sent. Public or private key encryption may be implementedwithin a system according to the invention without impact. Since aservice book 32 can be packaged at the service offering 16 point, allintermediary network hops can route the message without regard to themessage content. Therefore an encrypted message remains encryptedbetween a service offering and the mobile device 100, thereby creatingan end-to-end secure communication link. An exception to this would bewhen the service book clearing house 10 is used. In this case theservice offering 16 and the service registry 10 would either share acommon encryption method or they would not encrypt service book 32 databetween them.

[0055] Turning now to FIG. 6a this is a presentation of a user interface(UI) for service book entries 32 in which specific UDDI service books 32are cached on a mobile device 100. When a new registry entry arrives theuser could be working anywhere in the many mobile device 100sub-systems. In this example the user is working in a unified eventslisting screen 160 perhaps looking at previous events or about to read amail message, about to respond to a mail message, or many other possibletasks. The mobile device 100 might first notify the user that a messagehas been received on the mobile device 100, perhaps through an audiblealarm, through a visual alarm on the screen or through a visualindicator like a physical light on the mobile device 100. At this timethe user might be able to dismiss the interruption, or might be giventhe illustrated new service book arrival dialog box 162. This dialog box162 could have many configurations and formats, this is just onerepresentation. There could also be many user interfaces to the UI aswell, including touch screen input, menu selection input, push buttons,mouse movements, keyboard input and others just to name a few. In thisrepresentation the UI shows as many pertinent service book 32 elementsas possible. The dialog box also allows the user to DELETE, ACCEPT,ACCEPT & PROVISION or DEFER the new service book entry — as buttonchoices in the dialog box itself. The ‘delete’ action effectivelyremoves it from the mobile device 100 and the service is ignored. The‘accept’ action will accept the new service book entry, and if advancedprovisioning is required defer this to a later time. The accept choicemay, in some circumstances, also add a new menu option to the main menuof the handheld device 100. This could be used later for launching thenew service. The ‘accept and provision’ action will accept the newservice book and start the provisioning process. The ability toautomatically start provisioning might involve starting to download anapplication to be used with the host service; this is described later ingreater detail. The ‘defer’ action is similar to ‘ignore for now’ andthe user will be able to enter the service book sub-system to review thenew service book entry in greater detail before accepting it. This finalapproach is most common when the service book 32 is somewhat unexpectedby the user and they want additional time to consider their choices.However, even after accepting the service book it is always possible toremove the entry later if the user is not happy with the nature orbehaviour of the host service offering.

[0056] In this example many of the service book's 32 elements arepresented to the user, but some may have to be left off depending on theimplementation. Naturally, it would be possible to include the entireservice book 32 contents and allow the user to scroll or traverse theentire contents. The selection of which elements to show first, secondor last are arbitrary and do not affect the usefulness of the inventionitself. In this illustration the business elements are most useful forhelping the user to determine the purpose of the service book 32.Normally new service books arrive infrequently on a mobile device 100,so each time they do arrive they are important events for the user topay close attention to. The service book id is shown as Joe_Trade-234 isa reference number that might be used later, or it could be used inprovisioning over the phone. The service name itself is a user-friendlystring that gives a description of the purpose of the service. Theservice name also has a description attached showing that the E-Tradeservice is for performing stock trades and getting stock quotes. Thecompany offering the service is called ‘Bank of America’ which wouldnormally be included to inspire confidence and trust in the serviceoffering. Ideally the service offering would include a monthly charge,in this example that is $9.95 per month. The security method used on theservice book 32, considering it arrived over the air to the mobiledevice 100, is also important. In this example the network operator,helping to confirm that the service book is legitimate, signed theservice book 32. In this example there is advanced provisioning required— a Java application must be downloaded. Since the user is shown to bean existing customer of the bank, the bank is extending the existingcustomer status to include wireless access to their stock portfolio. Inother example the bank might have requested a credit card or bankaccount number to confirm a line of credit to cover the monthlyexpenses. Finally, after reviewing the information the user makes adialog box menu or button choice to clear the dialog box to continuewith their work. In this example if the user selects ‘Accept andProvision’ the downloading of the application will preferably take placein the background so the user will be able to continue with other work.As described earlier the location of the download will be embedded inthe service book 32 as received from the host service 16 or the servicebook clearing house 10. The download process is described in furtherdetail later in the provisioning section.

[0057] Turning now to FIG. 6b, this shows an example of what the servicebook sub-system 164 might look like on the mobile device 100. Theservice book sub-system 164 might be accessible from the main menu ofthe mobile device, or perhaps even from the options sub-system, thereare many possible embodiments. Like other sub-systems the service booksub-system 164 shows all the currently held service books 32 in a scrollbar method for easy access. Naturally other embodiments are possiblelike using a touch screen scroll bar, using a mouse wheel or thumbwheel. Each line represents a different service book that is eitheraccessible to the user, or is pending for the user to review. In thisexample the arrow has stopped at Joe's E-Trade service, which is alsoshown as pending. For illustration the arrow pointing represents thecursor location and the focus of the user's attention. In this UIillustration each service also has a icon depicting the service — thesecan be used to reduce the user's time when searching for services. Themethod of how the service came to arrive onto the mobile device 100 isalso shown. It is expected that some user customization might be allowedso that they can view exactly what suits them. This is similar to how auser can custom an e-mail viewing window to select from subject fields,time fields and from fields of each e-mail message. As the user scrollsthrough the list they can at any time invoke a menu of choices 166 thatcan be performed on any given service book entry. The user also mightcancel the menu of choice 166, or even leave the service book sub-system164 altogether.

[0058] The menu of choice represented here is only an example andadditional options are possible. Starting from the top of the list theuser can close the menu and return to scanning the entire list ofservices. The user can ‘open’ an item and look at an even more detailedview of all the elements of the service book entry. The user can‘delete’ the service book entry. The user can ‘sort’ the items, perhapssorting by all items received wirelessly. The user can ‘accept’ an item,for example if an item is pending (shown with Joe's E-Trade) they canaccept the item so that it is considered usable thus allowingprovisioning to take place. In many cases the accept choice may also adda menu item to the main menu, showing all available applications on themobile device 100. The advantage of this would be for easy access andfor fast launching of the application at a later time. However, ifdownload of an application is required then the accept choice wouldprobably NOT place an icon on the main menu. The item can beprovisioned, for example the Sport-R-Us service has been accepted, buthas not been provisioned. The user can try to force a ‘download’, whichmight be needed as part of provisioning. This could optionally have theside effect of checking for an updates to the software used with aservice. Once the download is complete the application's startupalgorithm might be executed which would place a icon on the main menu.This icon would allow for easy access to the new program and would allowthe user a quick launch method. The user can also select to modify the‘options’ supported in this sub-system. The options could includedisplay options, auto-acceptance options or other advanced service bookfeatures. Finally in this example the user could exit the service booksub-system.

[0059] 2. Service Provisioning and Application Download

[0060] A limitation in the current art of dynamic service description,discovery and integration is the concept of service provisioning. Thisterm can mean many things depending on the definition, so thisapplication will propose some language to help understand the step ofprovisioning. Due to the wide variety of host services available, andtheir complex nature, each one could require slightly different elementsto ensure that it is provisioned. The highest-level definition forservice provisioning in this application would be: “performing thenecessary steps to fully utilize a service offering after havingdetected its existence”. In this definition it is assumed that the userhas detected the service, such as by receiving the service book, and theuser desires to use the service in question. These necessary steps touse the service in question will normally include following one of thefollowing methods, although the following list does not represent acomplete list of methods possible for provisioning:

[0061] (1) Once the service book has been accepted the user simply hasto invoke an icon on the main menu. In this situations the resident webbrowser on the device will be launched with a URL on the command linethat would immediately be reached to find the target host service.

[0062] (2) The user performs a manual or automatic provisioning step anddownloads a Java application that places an icon on the main menu. Theapplication detects the service book entry, to identify the address ofthe corresponding host service, and when launched proceeds to exchangedata and perform service activities.

[0063] (3) The user first downloads a Java application to the mobiledevice 100. The user then launches the application and it confirms theservice book entry is present to find the host service. The applicationthen prompts the user for a user name and password to access the hostservice more securely and to confirm identity.

[0064] (4) The user first downloads a Java application to the mobiledevice 100. The user then launches the application and it requests acredit card number and expiry date. This information is sent securelyback to the host service and a credit check is preformed on the userrequesting the service.

[0065] (5) The user first downloads a Java application to the mobiledevice 100. The user then launches the application and the user name,address and contact information is taken by the application. A quickcheck is performed with the host service to confirm the user is known orunknown. The user is then given a dialog box asking them to call aspecific number to be provisioned to use the service offering.

[0066] (6) The user first downloads a Java application to the mobiledevice 100. The user then launches the application and it confirms theservice book entry is present then it prompts the user to enter a numberfrom a SecureID™ token provided for advanced security into the hostservice.

[0067] (7) The user first downloads a Java application to the mobiledevice 100. The service also comes with a smart card reader, retinalscanner or finger-print scanner which is attached to the mobile device.The user then launches the application and it requests that the userenter their smart card, provide a retinal scan or provide a finger printbefore being allowed to access the service offering.

[0068] Turning now to FIG. 7 there is an example of provisioning in awireless environment This illustration depicts a sample set of stepsused to establish the service, download the necessary application,confirm credit and payment terms and finally to access the serviceoffering. This visual representation is complemented by FIG. 8, thatuses a time sequence diagram to show the same steps in another way. Thefirst step (A) that takes place just before provisioning is that themobile device 100 user gets a new service book 32. The service book 32might have been retrieved using a ‘pull’ browser model, it could havebeen pushed to the mobile device 100, for example, using a methoddescribed above with reference to FIGS. 3 and 4. Once this user hasaccepted the service book 32, then the user can perform a provisioningstep (B) like downloading the necessary application to support theservice offering 16.

[0069] The application download URL within the service book 32, mightdirect the mobile device 100 to one or more computer systems 180dedicated to downloading applications. The advantage of this would bethat the service offering 16 machine will be able to perform the servicebetter and the heavier overhead of downloading is offloaded to anotherset of computers 180. Within this set of download computers 180, wouldbe a downloader application 182, specifically built to performingstreaming download of large Java (J2ME) programs to the mobile device100. Java 2 Micro Edition (J2ME) is a recent standard from SunMicrosystems™ that defines a subset of normal Java for small handheldand wireless devices. The J2ME version of Java is designed forover-the-air download with low overhead and size. Java is not the onlydownloadable format for programs and others are possible like C# (CSharp) from Microsoft™ and other proprietary interpreted and compiledprogramming language formats. Since the application download is runningthe background, however, the user is typically unaware of the timerequired to complete a download. Once the application is fullydownloaded it might be given a chance to run a startup routine, orperhaps part of the download allowed the main menu icon to be specified.The downloaded application may provide an icon for the main menu so theuser can easily launch the new application.

[0070] Once launched, the downloaded application checks to ensure thecorrect service book 32 is present on the mobile device 100. This willensure the user hasn't deleted it, or the application hasn't been loadedon a given mobile device 100 in error. The application will either checkfor the service identifier, or it could use a series of defined UDDIInterface calls to explore the local service book cache for the correctentry. Once launched the application could then perform a range ofactivities depending on what the downloaded program (for example J2MEsoftware) has been designed to do. In this embodiment the J2ME programprompts the user for personal information, address information andcredit information. While it is running it also communicates to theother sub-systems on the mobile device 100, like the operating system,to determine the mobile device type, the capabilities of the device, theCPU speed, the memory size, the network type, the screen size, the inputmethods and any other pertinent information that could be used by theservice offering. This information is then sent to the service offering16 computer (D) to perform the second stage of provisioning. The serviceoffering 16 might do several things with the information. It could logthe information for later usage or review. If mobile device 100information is present, it will save this information for each hostsystem to access when full two-way communications are confirmed. Itmight also prepare and send a credit check message to a bank or creditcard clearing house (E). Based on the response on credit authorizationthe service offering 16 will respond back with an positive or negativeacknowledgement on the service initiation request (F). If the response(F) is positive, the user of the mobile device 100 is then able to starta full two-way dialog (G) with service offering 16.

[0071]FIG. 8 uses a sequence diagram to illustrate the steps necessaryin an exemplary method of provisioning. The steps can be seen asprogressive in nature. At any stage if the previous steps haven't takenplace the process stops. If the user never downloads the applicationcredit approval can never take place.

[0072] 3. One Implementation Embodiment

[0073] Turning now to FIG. 9, one sample internal design for the servicebook components on the service offering 16 and the mobile device 100 isshown. The service offering 16 is normally surrounded by a firewall 64that protects all information from the hackers on the Internet 130. Theservice offering 16 is normally connected through one or more networkconnections (130, 140 and 150) to the mobile device 100. For the sake ofthis illustration this connection is performed by the wirelessconnection manager 60 a, which is one component in the wirelessconnector 60, previously described. The wireless connection manager 60 acould use many protocols and methods to exchange data with the mobiledevice 100. The most likely protocol would be some form of data exchangeover TCP/IP or UDP/IP. This data exchange could use SMTP to carry UDDImessages, with SOAP commands, in an XML format to the mobile device 100.The data exchange could be a proprietary service book 32 format, overTCP/IP using a FTP data exchange protocol. It should be understood,however, that there are many ways to exchange data elements, dependingon what is supported through the wireless network and within the mobiledevice 100.

[0074] The wireless connection manager 60 a also offers an API to othercomponents on the service offering 16. In this example there are threehost services 220 a, 220 b and 220 n all offering a distinct and uniqueservice. The host services also have access to a device Id andcapabilities database 60 d that provides the relationships to the mobiledevices 100. In this embodiment once a host service 200 a is started itwould communicate to the device Id database 60 d and determine a list ofmobile devices 100 it wished to offer the service to. This determinationcould be based on a configuration file for the host service 220 a, or itcould be a blanket offering opened to all existing and known users.There are many ways this device Id database 60 d could have been buillFor example each time a mobile device 100 was plugged into a serial porton the corporate LAN, its device Id information could have beencollected and stored in the database 60 d. Alternatively, a serviceoperator may have input the information manually into the database 60 d;for example through a point-to-point phone conversation. Anotherembodiment could have the database being built via a web interface,where mobile device 100 users enter their wireless information anddesired services. The database will also be updated to indicate whichservice books 32 have been transmitted to the mobile device 100. Thiscan be used later for management and diagnostic purposes. When themobile device 100 accepts the service book 32 and a response is receivedthe capabilities are then added to this database so that a master listof mobile device 100 capabilities can be kept for host service access.

[0075] Once the host service 220 a determines which mobile devices 100want their service offering 16, they request help from the wirelessconnection manager 60 a. The wireless connection manager 60 a exposes anAPI to allow any host service 220 a to request service books 32 be builtand sent to mobile devices 100. As described above, there are at least 4methods that these service books 32 could reach the mobile device. Thehost service 220 a might request that the service book 32 be sent to aUDDI Service Registry 8, using traditional UDDI registration methods.The host service 220 a might request that the service book 32 beextended with wireless information and provisioning data and sent to theUDDI Service Registry 8. This would eventually have the effect ofpushing a new service book 32 to the correct destination mobile device100. The third method is that the host service 220 a might request thatthe service book 32 be sent directly to the mobile device 100, using apush technique. The fourth method could be that the host service 220 aonly wants the service book 32 to be exchanged over a close proximitylink, like a local serial port. This selection process is all part ofthe API offered by the wireless connection manager 60 a. The wirelessconnection manager 60 a then turns to the service book processor 60 b toperform the step of creating the necessary service book format. Thismight also include compressing, encrypting and packaging the informationfor delivery. The service book processor 60 b might also encapsulate theinformation into an SMTP message, or a UDDI message as required.

[0076] Turning now to the mobile device 100 in FIG. 9 the main wirelessinterface point is the radio interface layers 230 and the operatingsystem (O/S) within the mobile device 100. The radio layers 230 withinthe mobile device 100 are the first to get information and pass it up tothe O/S and eventually up to the Java Virtual Machine (JVM) whenpresent. Using Java is optional but it is an exemplary method forcreating an extensible mobile device 100 platform. The service bookmanager 234 will be connected to the O/S or JVM like the other majorwireless programs on the mobile device 100. The service book manager 234will recognize and decode the service book 32 as it arrives in. Theservice book will use O/S or JVM resources as necessary to decompress,decrypt and unpackage the information so that it can be presented to theuser. The service book manager 234 is one of many service bookcomponents 238 on the mobile device 100. To assist the service bookmanager 234 is a User Interface (UI) program 164 that presents the newlyarrived service book 32 to the user for evaluation and review. The usercan then accept the service book 32 right at the time of arrival, orthey can defer the decision to a later time and re-enter the servicebook UI 164 at their leisure. On the mobile device is a cache ordatabase 236 of all accepted or pending service books 32. The servicebook database 236 is a resource to the service book UI 164 as itpresents options and alternative to user for manipulating known servicesto the mobile device 100.

[0077] Once the user starts provisioning, the service book manager 234exposes an API to the service book UI 164 that allows a download tocommence. Part of the service book manager 234 implements a very smallportion of a web browser, or a similar functionality to fetch a resourcelocated at a specific URL. Within the service book 32 itself is theaddress information (URL) that is used to locate the download file,related to the service book just accepted and provisioned by the mobiledevice 100 user. Once the download completes the newly loaded deviceapplication 232 a, 232 b or 232 n uses the service book manager's 234API to review known service books 32. It extracts the informationnecessary, based on a keyword string like the service name, to reach thecorrect destination service offering and also what further provisioningis required. If necessary it prompts the user for information, likecredit information and proceeds to send this to the host service asdefined in the relevant service book 32 section. This information mightalso include device capabilities reachable through the O/S and/or JVMwhen present; this was described earlier in this application. Once thehost service 220 a, 220 b or 220 n, is known and provisioning iscomplete, the mobile device application 232 a, 232 b or 232 n opens acommunication link for data exchange.

[0078] This internal representation of the service offering 16 and themobile device 100 illustrations just one possible implementation of thesoftware needed to perform the invention. It should be understood thatmany other implementations are possible, for example a separate servicebook database could be maintained on the service offering 16.

[0079] Turning now to FIG. 10 this represents a flow diagram for how aUDDI Registry node may handle a modified UDDI XML schema message. Thefirst step in this data flow diagram is the preparation of a servicebook message 300. This service book message 30 or 32 might follow theUDDI XML schema exactly 30, as defined by the UDDI specificationspublicly available. This message may extend this UDDI XML specification32 and use some proprietary wireless extension, or it might use aproprietary format and a private Service Book Clearing House 10 asdescribed in FIG. 5. Once this message has been sent it is received byone of many UDDI Registry nodes 302. In an exemplary implementation thetransmission would take place over the Internet and follow standardTCP/IP transmission techniques and the format would follow thespecifications for UDDI data exchanges. During this reception themessage is opened and examined to determine the type of command and theaction required 304. A test is then performed by this UDDI registry nodeto see if the UDDI XML schema has been extended to include wirelesssections 306. If it does not then the full UDDI processing is performedand the service offering is placed in the UDDI service cloud with allother public services 308.

[0080] If the UDDL XML schema does have wireless elements 306 the newwireless elements are extracted 310 and the required directives areassembled. There could be many mobile device's listed in the wirelesssection and for each one a series of steps are performed 312. First thetype of route is examined 314, for example which wireless network typemust be used to reach the mobile device 100. As shown in FIG. 5 the pathto the mobile device 100 could go directly to the wireless network 150 bor through a wireless infrastructure 140. In the later case manyconnections to wireless networks 150 could be abstracted through the onecommon interface. If the UDDI registry node does not have a path, orcannot support the specific wireless network then normal UDDI processingis performed and the service book is added to the registry 316. If thenetwork requested can be supported 314 a further test is performed toensure that the requested delivery method is supported 318. The deliverymethod or encapsulation of the service book might require a UDP/IPdelivery or TCP/IP, using FTP, SMTP or some proprietary deliveryprotocol. If the method cannot be supported the UDDI registry nodeproceeds to perform normal processing and places the entry into theregistry 316. Otherwise the wireless processing continues as the UDDInode builds the service book message following the requested format 320.Then the service book is sent, or pushed, to the mobile device 100following the delivery method defined in the original service bookmessage 322. Then after the processing is complete or the wirelessdelivery notification the UDDI registry node performs the normalprocessing and places the service book into the registry 324. If thereare more wireless addresses present the process continues, until alladdresses are checked and processed. When there are no wirelessaddresses remaining the UDDI process node returns to a steady state towait for further commands and work to do 326. These steps highlight, ata high level, a straightforward method to extend the UDDI operation tohandle a wireless extension to the XML schema defined for UDDI commandoperation. With the support of push delivery mechanisms in new wirelessnetworks the ability to use standard TCP/IP and UDP/IP datagrams to pushinformation to handheld devices makes this extension to UDDI possible.

[0081] Turning now to FIG. 11 this represents a flow diagram for how ahost service prepares and sends a service book. The data flow startswhen a host service starts and detects that it must send out servicebook information to mobile devices 340. The host service could be newlycreated, and detects that none of the existing users have received aservice book. It could be that the host service has been notified of achange to the Device Id database file, where a new user has been enteredfor the service. Alternatively the program may have been launched with afile of new users, or a single Device Id on the command line of theprogram. The host service might be one of many host services within aservice offering 16, as shown in FIG. 9. If the host service doesn'thave the one or more device identifiers it will need to determine them.These mobile device 100 identifiers mobile are used to targeting oraddress the new service book entries 342. There are many ways one ormore mobile device addresses can be discovered. In the descriptionsprovided for one embodiment, in FIG. 9, the mobile device has pluggedinto a serial cradle and the device identifier has been placed into aDevice Id and Characteristic database. An operator might have enteredthose user's mobile device addresses that want the service. They couldbe received over the air, or from a web site where users register forthe service offering.

[0082] After having collected the necessary mobile device addresses, thehost service can either build the service book directly or request aservice book manager or formatter to assist in building the servicebooks 344. This could be an single application program interface (API)call, or it could take many interactions to build the one or more datastructures used for service book delivery. The service book creationwill include following either a standard format, like UDDI XML schemas,or a proprietary format depending on what the device characteristicsare. At this stage the service book might also include the variousprovisioning requirements, which might include one or more of thefollowing requirements: (1) application downloading, (2) downloadaddress information, (3) credit information, (4) type of creditinformation required, (5) personal and addressing information andoverall service length, type and variety. This is not an exhaustive listbut a representative list of the types of issues and questions thatshould be resolved during the provisioning stage of using a hostservice. In an exemplary embodiment this information is kept secretbetween the host service and the mobile device user.

[0083] The next step is to determine if the service book will be sentover-the-air (OTA) or through a close proximity link 346. If the servicebook needs the highest level of security, or if the system doesn'tsupport OTA service book delivery, then it will use a serial port, IRDAlink, RF link, Bluetooth method, or some other close range method fordelivering the service book. In this case the provisioning section mightbe modified to reflect what is needed and it is possible that anynecessary Java applications could be downloaded when the mobile deviceis in close proximity. Then the service book, with any provisioningrequirements, is placed in the service book database, or the Device Idand characteristics database. When the mobile device makes itself known,through a close proximity link, the new service book and any necessaryapplications will be downloaded to the mobile device — normally with theuser's permission.

[0084] If the service book is going to be sent over the air (OTA) 346,the OTA processor checks the mobile device capabilities, or theconfigured information entered during registration, to see what specialmessage preparation should be preformed. In an exemplary embodiment theservice book is compressed and encrypted so that only the user of themobile device is capable of opening and reading the entire contents ofthe service book information 352. Once the service book is prepared forthe mobile device, a check is preformed to see if the service book isbeing sent directly to the mobile device, or it will go through aservice book registry, like the UDDI registry 354. There is the optionof sending it to the UDDI registry only, which no further redirection tothe mobile device 100, but this logic is not shown here, as it does notapply to this application. If the service book message is going directlyto the mobile device, the final packaging is performed on the servicebook 356. Then the service book is sent using the required method 358,which could have been configured by the original mobile device user whenthey requested the service. The message could be sent via a specifiedMIME part within an E-mail message, via an extended SMS, EMS or MMSmessage, via FTP over TCP/IP, or using a proprietary method over TCP/IPor UDP/IP.

[0085] If the delivery method is to use a registry, like the UDDIregistry 354, the first step is to added wireless routing elements sothat the one or more mobile devices can receive the service book 360.The message to the UDDI registry node may include only a single mobileaddress per message, or it may contain a list of mobile devices allwanting the same service book. In either case, all the necessary routinginformation is appended to the optionally secure service book so thatthe UDDI registry node can push the service book to the mobile deviceuser 360. This information could include the device identifier, thewireless network name and type used by the mobile user, and the deliverymethod that must be used to push the information to the user. Finallythe message is prepared for shipment to one of many UDDI registry nodesand it is sent 362. It should be understood that there are many optionsthat could be used, for instance both UDDI and proprietary service bookclearing house methods could be used, either independently or together.In addition, it is possible that many sends could take place to ensurepopulation to the correct registry supporting the user. Since there isvery small negative impact if the user receives the same service bookmore then once, multiple sends to different registry locations arepossible.

[0086] Depending on the API calls, and how the original mobile deviceaddresses were prepared, this process may continue until all mobiledevice addresses are handled. In one embodiment, mobile device addressesmay be grouped based on how they wish to receive the service book. Inthis method a group of common mobile devices all are processed at onceand the next time through the loop another group of mobile deviceaddresses are processed.

[0087] Turning now to FIG. 12 this represents a flow diagram for how aservice book is processed on a handheld device. The first step is thearrival of a message containing a service book 370. This could arrive indirectly via a TCP/IP link, or it could have arrived within an e-mailmessage, or even via a native wireless network protocol. The informationwithin the service book could be encrypted and compressed, so the nextstep would be to perform decryption and decompression as required 372.Once the contents are extracted and some verification takes place, theuser can be notified of the new service book and a dialog placed on themobile device's screen 374. The dialog box could present one or morefields within the service book to the user. The design of the dialog boxis important and in an exemplary implementation the dialog box has afull description, the costs and the service provider information. Thegoal is to assist the user to identify why they have received theservice book, who it comes from and do they want to accept it onto theirmobile device.

[0088] As they review this information they make the decision to accept,reject or defer action on the service book until later 376. If theydefer action the service book is placed into the service book database378, which is effectively a local cache of all relevant service bookentries for this particular user. The entry is marked as pending, sothat the user can quickly identify it when they enter the service booksub-system and access the service book UI. If the user has not deferredthe service book they might have either accepted, accepted andprovisioned or deleted the service book. If they truly don't like ordon't understand the received service book they can immediately have itdeleted from the device 386. If they accept the service book this willplace it in the service book database without a ‘pending’ indicator onit. For some services this might be the only step necessary to use agiven service, for example when the necessary application is already onthe device and the routing information out of the service book is allthat is required. If the user does perform an accept 380, the servicebook entry is checked to see if provisioning is required, if not anyicon that appears in the service book entry is placed on the main menuof the mobile device 382. Adding the icon to the main menu is anoptional step but can make finding and launching the new host serviceeasier. In some cases the icon will simply call an existing mobiledevice browser application with a new URL. The application is placed inthe service book database and marked accepted, not pending 384.

[0089] If the user has decided to accept and provision the application380 they are taken to a step within the data flow shown in FIG. 13.Performing the provisioning step from the dialog box automaticallyperforms an accept, followed by any provisioning steps that might berequired. In this example the provisioning steps shown will includedownloading an application for the host service and collectingcredit-checking information from the user.

[0090] Turning now to FIG. 13 this represents a flow diagram for how theuser interacts with the service book sub-system on a handheld device.The first step in the data flow is when the user decides to enter theservice book sub-system 400. The service book sub-system presents allknown and pending services to the user and presents them with a friendlyUI to select menu choices and options 402. The choices in thissub-system can be very extensive. It should be understood, however, thatthe options described in this data flow are representative of the mostcommonly used methods for manipulating database entries that havecharacteristics similar to service book entries.

[0091] If the user selects to ‘open’ the service book 404, the currentservice book entry is opened and a new dialog box or screen is presentedto the user 406. This opened service book may be more extensive then theone shown when the entry first arrived, and the user would be able toscroll or move through all fields of the service book. While in thisscreen the user could perform the same actions as shown, includingdeleting, accepting and provisioning. If the user decides they don'twant the service book entry on the device any longer, they can select todelete the service book 408. In this case the service book entry isremoved from the database cache 410 and the software returns to theservice book main menu, where the user can exit the service booksub-system if they want.

[0092] If the user doesn't delete the entry they might decide to accepta pending entry 412. In this case the service book is marked asaccepted, not pending 414. If no provisioning is present, any providedicon information is placed on the main menu with invocation instructionsfor the correct application 416. The software then returns to wait formore user input or to exit the service book sub-system. If the user hasalready accepted, or if they want to both accept and provision a pendingservice book, they can select the provision menu item 420. This path canalso be entered if the user decides to provision directly from theoriginal service book notification dialog box 418. In this case theservice book is marked as accepted, if it was pending, and the entry ismarked as download in progress 422. Any necessary information to startthe download is extracted and sent to the specified download address tostart the process 424. The download then. takes place, which may or maynot been seen by the user. This activity could be a background activity,or the user might be given the option of watching a progress bar.

[0093] Once the application has been download the security for theapplication is checked. This could be done using a signature technique,where one or more parties that have a stake in its quality have signedthe application. These stakeholders represent an implied quality ortrust level that may also be presented to the user before theapplication is given any CPU cycles to perform initialization 426. Ifthe user accepts the application, or if it was an automatic download andrun application, the application performs its initialization 428.Initialization might reserve resources, perform database setup andinitialization and could set an icon on the main menu for the user 430.

[0094] The user could also have selected a range of other commands inthe service book sub-system 432. One such command could sort entriesinto pending and not pending, or wireless and serial entries. Anothercommand could create sub-views, or sorted views of the services tocreate a hierarchical view. There could also be commands that couldperform ‘ping’ tests to the host service to ensure the host service isstill on-line. There could also be options to change the main servicebook listing view. Perhaps the user decides to see the time the servicebook entry was received, or the service name, or the service type, orthe description string, there are a large number of options available tothem. Once these commands are performed the user will return and enterother commands until they exit the service book sub-system.

[0095] Turning now to FIG. 14 there is a block diagram of a mobilecommunication device 100 in which the dynamic expansion of host servicesmay be implemented. The mobile communication device 100 is preferably atwo-way communication device having at least voice and datacommunication capabilities. The device preferably has the capability tocommunicate with other computer systems on the Internel Depending on thefunctionality provided by the device, the device may be referred to as adata messaging device, a two-way pager, a cellular telephone with datamessaging capabilities, a wireless Internet appliance or a datacommunication device (with or without telephony capabilities).

[0096] Where the device 100 is enabled for two-way communications, thedevice will incorporate a communication subsystem 911, including areceiver 912, a transmitter 914, and associated components such as oneor more, preferably embedded or internal, antenna elements 916 and 918,local oscillators (LOs) 913, and a processing module such as a digitalsignal processor (DSP) 920. It should be understood, however, that theparticular design of the communication subsystem 911 is dependent uponthe communication network in which the device is intended to operate.For example, a mobile device 100 destined for a North American marketmay include a communication subsystem 911 designed to operate within theMobitex™ mobile communication system or DataTAC™ mobile communicationsystem, whereas a mobile device 100 intended for use in Europe mayincorporate a General Packet Radio Service (GPRS) communicationsubsystem 911.

[0097] Network access requirements will also vary depending upon thetype of network 919. For example, in the Mobitex and DataTAC networks,mobile devices such as 100 are registered on the network using a uniquepersonal identification number or PIN associated with each device. InGPRS networks however, network access is associated with a subscriber oruser of a device 100. A GPRS device therefore requires a subscriberidentity module (not shown), commonly referred to as a SIM card, inorder to operate on a GPRS network. Without a SIM card, a GPRS devicewill not be fully functional. Local or non-network communicationfunctions (if any) may be operable, but the mobile device 100 will beunable to carry out any functions involving communications over network919. When required network registration or activation procedures havebeen completed, a mobile device 100 may send and receive communicationsignals over the network 919. Signals received by the antenna 916through a communication network 919 are input to the receiver 912, whichmay perform such common receiver functions as signal amplification,frequency down conversion, filtering, channel selection and the like,and in the example system shown in FIG. 9, analog to digital conversion.Analog to digital conversion of a received signal allows more complexcommunication functions such as demodulation and decoding to beperformed in the DSP 920. In a similar manner, signals to be transmittedare processed, including modulation and encoding for example, by the DSP920 and input to the transmitter 914 for digital to analog conversion,frequency up conversion, filtering, amplification and transmission overthe communication network 919 via the antenna 918.

[0098] The DSP 920 not only processes communication signals, but alsoprovides for receiver and transmitter control. For example, the gainsapplied to communication signals in the receiver 912 and transmitter 914may be adaptively controlled through automatic gain control algorithmsimplemented in the DSP 920.

[0099] The mobile device 100 preferably includes a microprocessor 938which controls the overall operation of the device. Communicationfunctions, including at least data and voice communications, areperformed through the communication subsystem 911. The microprocessor938 also interacts with further device subsystems such as the display922, flash memory 924, random access memory (RAM) 926, auxiliaryinput/output (I/O) subsystems 928, serial port 930, keyboard 932,speaker 934, microphone 936, a short-range communications subsystem 940and any other device subsystems generally designated as 942.

[0100] Some of the subsystems shown in FIG. 11 performcommunication-related functions, whereas other subsystems may provide“resident” or on-device functions. Notably, some subsystems, such askeyboard 932 and display 922 for example, may be used for bothcommunication-related functions, such as entering a text message fortransmission over a communication network, and device-resident functionssuch as a calculator or task list.

[0101] Operating system software used by the microprocessor 938 ispreferably stored in a persistent store such as flash memory 924, whichmay instead be a read only memory (ROM) or similar storage element (notshown). The operating system, specific device applications, or partsthereof, may be temporarily loaded into a volatile store such as RAM926. It is contemplated that received communication signals may also bestored to RAM 926. In this application the flash memory 924 of themobile device 100 also hold downloaded applications, such as Java(J2ME-based) applications downloaded 950 over the serial port, orover-the-air. The flash memory 924 also holds all known service books950, pending or accepted. If the mobile device 100 should reset, orexperience a failure these entries will not be lost and the user canstill accept pending entries at any time 950. Within the flash memory924 on the mobile device 100 is also other PIM and databases used forconfiguring and operating the software components of the system.

[0102] The microprocessor 938, in addition to its operating systemfunctions, preferably enables execution of software applications on thedevice. A predetermined set of applications that control basic deviceoperations, including at least data and voice communication applicationsfor example, will normally be installed on the mobile device 100 duringmanufacture. A preferred application that may be loaded onto the devicemay be a personal information manager (PIM) application having theability to organize and manage data items relating to the device usersuch as, but not limited to e-mail, calendar events, voice mails,appointments, and task items. One or more memory stores would beavailable on the device to facilitate storage of PIM data items on thedevice. Such PIM application would preferably have the ability to sendand receive data items, via the wireless network. In a preferredembodiment, the PIM data items are seamlessly integrated, synchronizedand updated, via the wireless network, with the device user'scorresponding data items stored or associated with a host computersystem. Further applications may also be loaded onto the mobile device100 through the network 919, an auxiliary I/O subsystem 928, serial port930, short-range communications subsystem 940 or any other suitablesubsystem 942, and installed by a user in the RAM 926 or preferably anon-volatile store (not shown) for execution by the microprocessor 938.Such flexibility in application installation increases the functionalityof the device and may provide enhanced on-device functions,communication-related functions, or both. For example, securecommunication applications may enable electronic commerce functions andother such financial transactions to be performed using the mobiledevice 100.

[0103] In a data communication mode, a received signal such as a textmessage or web page download will be processed by the communicationsubsystem 911 and input to the microprocessor 938, which will preferablyfurther process the received signal for output to the display 922, oralternatively to an auxiliary I/O device 928. A user of mobile device100 may also compose data items such as email messages for example,using the keyboard 932, which is preferably a complete alphanumerickeyboard or telephone-type keypad, in conjunction with the display 922and possibly an auxiliary I/O device 928. Such composed items may thenbe transmitted over a communication network through the communicationsubsystem 911.

[0104] For voice communications, overall operation of the mobile device100 is substantially similar, except that received signals wouldpreferably be output to a speaker 934 and signals for transmission wouldbe generated by a microphone 936. Alternative voice or audio I/Osubsystems such as a voice message recording subsystem may also beimplemented on the mobile device 100. Although voice or audio signaloutput is preferably accomplished primarily through the speaker 934, thedisplay 922 may also be used to provide an indication of the identity ofa calling party, the duration of a voice call, or other voice callrelated information for example.

[0105] The serial port 930 in FIG. 11 would normally be implemented in apersonal digital assistant (PDA)-type communication device for whichsynchronization with a user's desktop computer (not shown) may bedesirable, but is an optional device component. Such a port 930 wouldenable a user to set preferences through an external device or softwareapplication and would extend the capabilities of the device by providingfor information or software downloads to the mobile device 100 otherthan through a wireless communication network. The alternate downloadpath may for example be used to load an encryption key onto the devicethrough a direct and thus reliable and trusted connection to therebyenable secure device communication.

[0106] A short-range communications subsystem 940 is a further optionalcomponent which may provide for communication between the device 924 anddifferent systems or devices, which need not necessarily be similardevices. For example, the subsystem 940 may include an infrared deviceand associated circuits and components or a Bluetooth™ communicationmodule to provide for communication with similarly-enabled systems anddevices.

[0107] This written description uses examples to disclose the invention,including the best mode, and also to enable any person skilled in theart to make and use the invention. The patentable scope of the inventionis defined by the claims, and may include other examples that occur tothose skilled in the art.

We claim:
 1. A method of pushing a service book to a mobile device,comprising the steps of: providing the service book with a plurality offields relating to a host service; identifying at least one mobiledevice to receive the service book; providing wireless propagationinformation that identifies an address for the mobile device to receivethe service book; transmitting the service book over a wireless networkusing the address for the mobile device; and receiving the service bookat the mobile device.
 2. The method of claim 1, wherein the address forthe mobile device is an electronic mail address.
 3. The method of claim1, wherein the address for the mobile device is an identification numberfor the mobile device in a wireless network.
 4. The method of claim 1,wherein the wireless propagation information is one of the plurality ofservice book fields.
 5. The method of claim 4, comprising the furthersteps of: transmitting the service book from the host service to aservice registry via a computer network; and transmitting the servicebook from the service registry to the mobile device over the wirelessnetwork using the address for the mobile device.
 6. The method of claim5, wherein the computer network is the Internet.
 7. The method of claim5, wherein the service registry can be one or more UDDI registry nodeswith a UDDI registry network.
 8. The method of claim 1, wherein theservice book is transmitted from the host service to the mobile devicevia a close proximity link.
 9. The method of claim 8, wherein the closeproximity link is an infrared (IR) transmission system.
 10. The methodof claim 8, wherein the close proximity link is a serial connection. 11.The method of claim 8, wherein the close proximity link is a spreadspectrum wireless transmission system.
 12. The method of claim 8,wherein the close proximity link is a radio frequency (RF) transmissionsystem.
 13. The method of claim 1, wherein one of the service bookfields includes an Internet link to one or more download computers. 14.The method of claim 1, wherein the service book fields include awireless information field.
 15. The method of claim 1, wherein theservice book fields include a provisioning information field.
 16. Themethod of claim 1, comprising the further step of: storing the servicebook in a service book cache on the mobile device.
 17. The method ofclaim 16, comprising the further steps of: displaying the service bookcache using a user interface (UI) executing on the mobile device. 18.The method of claim 16, comprising the further steps of: providing amobile device user an option to accept or reject the service book; ifthe mobile device user accepts the service book, then storing theservice book in a service book database on the mobile device; and if themobile device user rejects the service book, then deleting the servicebook from the service book cache.
 19. The method of claim 18, comprisingthe further step of: notifying the mobile device user when the servicebook is received by the mobile device.
 20. The method of claim 18,comprising the additional step of: providing the mobile device user anoption to provision the service book; and if the mobile device userchooses to provision the service book, then activating the host serviceon the mobile device.
 21. The method of claim 20, comprising theadditional step of: providing the mobile device user an option to deferprovisioning.
 22. The method of claim 20, comprising the further stepof: if the mobile device user chooses to provision the service book,then downloading a software application from the host service to themobile device.
 23. The method of claim 22, wherein the downloadedsoftware application prompts the mobile device user for furtherprovisioning information, and wherein the further provisioninginformation is transmitted from the mobile device to the host service.24. The method of claim 23, wherein the further provisioning informationincludes credit information.
 25. The method of claim 22, wherein thesoftware application is downloaded from one or more download computershaving an address on a computer network.
 26. The method of claim 20,comprising the further steps of: if the mobile device user chooses toprovision the service book, then contacting the host service via thewireless network; and establishing payment terms for use of the hostservice by the mobile device.
 27. The method of claim 1, comprising theadditional steps of: encrypting the service book before transmitting theservice book over the wireless network; and decrypting the service bookwith the mobile device.
 28. The method of claim 27, wherein the servicebook is encrypted and decrypted using a public key infrastructure (PKI).29. The method of claim 1, wherein the service book identifies otherhost services available for the mobile device.
 30. The method of claim1, wherein the service book is transmitted using an electronic mailprotocol.